home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0054.004 < prev    next >
Text File  |  1991-05-31  |  36KB  |  890 lines
  1. Document: FSC-0054
  2. Version:  004
  3. Date:     27-May-1991
  4.  
  5.  
  6.  
  7.  
  8.                            The CHARSET Proposal
  9.  
  10.    A System-Independent Way of Transferring Special Characters, Character
  11.              Sets and Style Information in FIDO Messages.
  12.  
  13.                               Fourth Release
  14.  
  15.                                Duncan McNutt
  16.                              2:243/100@fidonet
  17.  
  18.  
  19.  
  20.  
  21. Status of this document:
  22.  
  23.      This is a finished specification, it is used in several FIDO
  24.      products.
  25.  
  26.      This FSC suggests a protocol for the FidoNet(r) community,
  27.      and requests discussion and suggestions for improvements.
  28.      Distribution of this document is unrestricted.
  29.  
  30.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  31.      Software.
  32.  
  33.  
  34.  
  35.  
  36. Contents:
  37. ---------
  38.   Purpose
  39.   History
  40.   Pros & Cons
  41.   The Present System
  42.   The Proposed System
  43.   Technical Details
  44.   Examples
  45.   Summary
  46.   Implementation Sample
  47.   
  48.  
  49.  
  50. Purpose:
  51. --------
  52.  
  53. This document is a proposal for a FIDO standard. 
  54.  
  55. This document describes a method of allowing international and other
  56. non-standard ASCII characters to be transferred via a network and
  57. interpreted by the receiving systems.  It also allows for expansion to
  58. multiple character sets and character sets that require more than one
  59. byte storage space per character.  Further the capability to include
  60. style and font changes are part of this proposal.
  61.  
  62.  
  63. This proposal is based on the ISO standard character sets.  It defines
  64. a mechanism to switch between all of the defined ISO sets.  Further it
  65. defines switches that allow style and font changes.  The FSC-0054
  66. standard also coexists with the extensions of the ISO LATIN-1
  67. characters set as defined in FSC-0051.  FSC-0054 and FSC-0054 use the
  68. same identifier (CHRS: LATIN-1 2) to indicate the LATIN-1 character
  69. set.  FSC-0051 (draft 3 and above) defines the codes unused in LATIN-1
  70. for additional characters.  At present these are the numeric super and
  71. subscripts as well as Polish characters.
  72.  
  73.  
  74. History
  75. -------
  76.  
  77. All in all the author is aware of 6 initial proposals for including
  78. additional characters in FIDO messages, most of them did not get the
  79. critical mass to achieve widespread use.  Three of them actually
  80. managed to get FSC numbers.  FSC-0054 and FSC-0051 effectivly merged as
  81. of this document.  FSC-0054 is backwardly compatible to FSC-0050.
  82. Another standard that was used in Denmark is no longer in discussion.
  83.  
  84. The initial proposal was FSC-0050.  It had several drawbacks, most
  85. notably it was too limiting and it was based around a particular
  86. hardware platform.  Because of its implementation in Opus, FSC-0054
  87. tries to recognize the messages produced by that system.  There are
  88. several incompatible "flavors" of FSC-0050 floating around, so FSC-0054
  89. can not always produce perfect results when translating FSC-0050
  90. messages.  Implementations that allow for FSC-0050 can use the same
  91. code for FSC-0054 but may need to generate different kludges and will
  92. need to be expanded a to make full use of the extra features.
  93.  
  94. A second proposal FSC-0051 had the advantage of hardware independance
  95. but lacked (on its own) expandability as it only allows for
  96. roman characters (ie: western languages).  Because the FSC-0051 and
  97. FSC-0054 methods both contain the LATIN-1 character set as the base set
  98. for western countries the authors agreed on a common identifier to
  99. allow the two systems to coexist.  FSC-0051 allows you to add Polish
  100. characters to the Latin-1 character set without necessiating complience
  101. to FSC-0054 Level 3.  FSC-0051 is mainly used in Sweden.
  102.  
  103. The system described in this document gives the maximum in capability
  104. without breaking the FIDO message format.  It allows hardware
  105. independance and internationalization of FIDO software.
  106.  
  107. To further enhance the capabilities of FIDO beyond what is described
  108. here a new message document format must be defined.  The author
  109. suggests this be done in connection with a type-3 format and that the
  110. Open Document Architecture (ODA) be included as the standard for that
  111. format.  ODA is the agreed standard for comercial mail systems and is
  112. being implemented by X.400 messaging systems.  Conformance to that
  113. standard would allow transfer between FIDO and other nets without
  114. translation.  ODA contains formatted text as well as graphics and
  115. sound.
  116.  
  117.  
  118. Pros and Cons:
  119. --------------
  120.  
  121.  
  122. Any form of non standard ASCII extension to the present messages
  123. must respect the following criteria.
  124.  
  125. It should:
  126.   o  be simple
  127.   o  be backwards compatible
  128.   o  be expandable
  129.   o  be transparent
  130.   o  allow for multiple levels of support
  131.   o  allow for translation to the least common denominator
  132.  
  133. Earlier proposals had several problems:
  134.  
  135.   1) They inserted non ASCII characters in the PRESENT stream of
  136.      messages.
  137.  
  138.   2) They did not allow for an easy to read "standard ASCII" represen-
  139.      tation on areas that do not support thier special encoding scheme.
  140.  
  141.   3) They increased the size of messages by a larger amount than is
  142.      necessary.
  143.  
  144.   4) They were hardware dependant.
  145.  
  146.   5) The implementation sample were too slow to be effective (a minor
  147.       point).
  148.  
  149.   6) They limited the possibilities.
  150.      They only allowed for a limited amount of graphic or other special
  151.      purpose characters.  They did not allow for character sets that
  152.      require storage space that are larger than one byte per
  153.      character.  They were not expandable.
  154.  
  155.  
  156. The advantages of the system proposed here are:
  157.  
  158. It does not have any of the failings of the prior systems (points 1-5).
  159.  
  160.   1) It does not insert any non ASCII characters in the present
  161.      stream of messages.
  162.  
  163.   2) It allows for an easy to read standard ASCII representation.
  164.  
  165.   3) It does not increase message size.  It only includes the charset
  166.      kludge in messages that use non-ascii characters (e.g.: Kanji).
  167.  
  168.   4) The presented algorithm is efficient.
  169.  
  170.   5) The presented algorithm is efficient.
  171.  
  172.   6) It support ALL international characters as well as graphic and
  173.      other special characters.  It allows for character sets that
  174.      require storage space that is greater than one byte per character.
  175.      It allows for future expansion.
  176.  
  177.  
  178.   7) It allows for a simple method of converting non-standard
  179.      characters to standard ASCII in present systems.
  180.  
  181.   8) It allows for character set coherence in message areas without
  182.      double processing.
  183.  
  184.   9) It allows multiple levels of complience.
  185.  
  186.   10) It concerns itself with gateway filtering of messages.
  187.  
  188.   11) The implementation allows non "charset kludge" aware programs
  189.       to display and edit messages.
  190.  
  191.   12) It concerns itself with network representation as well as
  192.       local storage.
  193.  
  194.  
  195. The present system:
  196. -------------------
  197.  
  198. The present system "normally" only uses standard ASCII, unless an
  199. echomail conference moderator explicitly allows non ASCII characters. 
  200. If a user does not conform to this and writes non standard ASCII in
  201. a message, then other users with different systems get garbage on
  202. their screens.  This can be (and in some areas is) a major problem.
  203.  
  204. At present there is no way to diplay non Roman characters in FIDO
  205. messages.
  206.  
  207.  
  208.  
  209. The proposed system:
  210. --------------------
  211.  
  212. The proposed system will be able to help with messages that do NOT have
  213. the CHARSET kludge in them on an area by area basis.  However manual
  214. intervention by the user will allow it to translate the alien codes to
  215. the local ASCII extensions.  It will also allow editors to more easily
  216. make standard ASCII representations of extended character sets.  Which
  217. hopefully will make more users conform to standard ASCII.
  218.  
  219. For messages with the charset kludge the method described below
  220. allows using extended character sets.  There are multiple levels of
  221. support:
  222.  
  223. Level 0: STANDARD message (no charset kludge).  This method adds an
  224.      option to convert non standard ASCII to ASCII.  Level 0 is
  225.      straight forward: don't change anything, except remapping non
  226.      standard ASCII to ASCII.
  227.  
  228.      This should be the initial default for any CHARSET message
  229.      writer.
  230.  
  231. Level 1: INTERNATIONALIZATION, accents and other language specific
  232.      characters are supported.  This is needed for echomail areas
  233.      that go through gateways to other systems that have a limited
  234.      character set.  Level 1 can be supported by ALL types of
  235.      computers!  It translates the standard US ASCII codes to the
  236.      foreign ISO codes and back.
  237.      
  238.      Most software only needs to READ this type of message.  This is
  239.      easily done with the sample implementation that is available
  240.      via SDS.  Most software should directly support level 2.
  241.  
  242. Level 2: Support for Level 1 plus EXTENDED CHARACTERS, included are
  243.          graphic characters and special characters from other character
  244.          sets such as greek (for mathematical discussions for example).
  245.          This is intended to allow the different personal computer,
  246.          workstation, mini and mainframe users to converse in text mode.
  247.  
  248.      The default for level 2 messages should be the LATIN-1
  249.      character set.  It is still compatible with the present stream
  250.      of messages.
  251.          
  252.      This is the most common level of support for most software.
  253.      It is also what the sample implementation concerns itself with
  254.      most.
  255.  
  256.  
  257. Level 3: Support for MULTIPLE CHARACTER SETS.  This requires a
  258.      greater effort in implementation.  Level 3 is (of course) not
  259.      backwards compatible.
  260.      
  261.      It is easiest to support level 3 if you use a pixel based
  262.      display, it is probably not worth implementing on a text only
  263.      display.  For example: if you have an X-Windows, Microsoft
  264.      Windows, Macintosh or similar display then you should have no
  265.      trouble implementing level 3.
  266.  
  267.  
  268. Level 4: Support for 16 BIT CHARACTER SETS.  Software authors
  269.      that support products that are intended for use in Asia should
  270.      concern themselves with this specification.
  271.  
  272.  
  273. The implementation algorithm which has been developed is a pop-in
  274. module that allows present message editor/display programs to offer
  275. Level 2 support for the 5 most popular systems (ASCII, IBM, APPLE, ISO
  276. Latin-1, VT100).  The Atari now uses the IBM character set, the Amiga
  277. and the VT200 displays use the ISO Latin-1 (ISO 8859-1) character set.
  278. This implementation is also usable as a filter for fast translation of
  279. messages in gateway software or for a packet translator.  See the notes
  280. at the end of this document for further details.
  281.  
  282. Levels 1 & 2:
  283.  
  284. Levels 1 and 2 are based on a remapping system. The following must
  285. be supported:
  286.  
  287.   o  Level 1: remapping of non standard ASCII foreign characters,
  288.      remaps characters that are less than decimal 128.
  289.   o  Level 2: additional remapping of special characters and
  290.      graphic characters, remaps characters over decimal 127
  291.      (i.e.: characters with the most significant bit set).
  292.   o  [optional] a style mechanism (bold, underline...)
  293.   o  [optional] font switching (times, helvetica...)
  294.  
  295. Characters below decimal 32 are reserved for special use (e.g.: the
  296. SOH character is used for message kludges).
  297.  
  298. Note: Basically a lot of international message areas contain a certain
  299. amount of messages with international characters.  These characters
  300. have the same codes on all systems, they are most likely known to you
  301. through your printer manual, VT100 foreign symbols, or as IBM
  302. codepages.  The only reason these codes are not displayed correctly
  303. is that your message reader can not know which of these character
  304. sets is used.  Levels 1 and 2 will mark the message with an ID that will
  305. let your message reader change the environment in such a way that the
  306. characters are displayed correctly.
  307.  
  308. The style mechanism and the font switching are fully transparent and
  309. backwards compatible.  Style changes are easy to support, even VT100
  310. and Hercules (on IBM-PCs) displays support underline and boldfaced
  311. characters.
  312.  
  313.  
  314. Remapping of foreign codes may take one of two forms selected by the
  315. user:
  316.   1) remap to character set supported by this system
  317.   2) remap to ASCII
  318.  
  319. Level 1 remaps 98% on all systems, Level 2 remaps with a "best
  320. match" algorithm.  It may be that results are not perfect but they
  321. should be recognizable.  See the Technical Description below for some
  322. examples.
  323.  
  324.  
  325. Levels 3 & 4:
  326.  
  327. Levels 3 and 4 require additional support that is non trivial. 
  328. However, it is not as complicated as it might seem at first. The
  329. following must be supported: 
  330.   o  a character set switching mechanism,
  331.   o  multiple character sets (roman, greek, cyrillic...),
  332.   o  character set remapping (fairly simple),
  333.   o  [optional] transliteration (not simple),
  334.  
  335. Transliteration (converting words and symbols to another representa-
  336. tion or language) is an optional feature that is supported by some
  337. operating systems (OS/2 and Macintosh as well as some UNIX systems).
  338. Transliteration is not really part of this proposed standard but is
  339. mentioned to bring the technical possibility to mind.  If your
  340. operating system supports it then transliteration is usually just a
  341. simple function call, if it doesn't then forget it.
  342.  
  343.  
  344. Levels 5 & 6:
  345.  
  346. Do not exist and are not (presently) proposed.  I was thinking about
  347. B&W bitmaps for level 5 and color graphics for level 6, however that
  348. is not suitable for Fido messages until ISDN becomes the standard
  349. medium of transport.  The physical (not logical) limit of 25000 bps
  350. on regular telephone systems is just not fast enough to allow the
  351. cost effective transfer of such large data amounts for a privately
  352. operating individual.  Even supposing a 10 to 1 compression of
  353. graphics, would not be nearly enough (color pictures could still
  354. easily be larger than 2 megabytes).
  355.  
  356.  
  357.  
  358. Technical Description
  359. ---------------------
  360.  
  361. This description gives a complete specification of levels 0 through 4.
  362. If you have needs that go beyond the specification of levels 3 and 4 as
  363. they are put forward here then please write the author.
  364.  
  365. As mentioned before the proposed method for levels 0 through 2 relies
  366. on remapping.  Remapping is fairly straight forward on almost all
  367. hardware plat- forms.  It is easiest on graphically oriented systems
  368. such as the UNIX X-Windows, Apple machines, Commodore Amiga, Atari ST
  369. and IBM Presentation Manager or Windows systems.  But even on text only
  370. displays such as IBM DOS, VT100 and Commodore 64 machines the most used
  371. characters are fairly easily available.  Helpful in this endeavor is
  372. that the foreign characters and additional special characters are often
  373. the same on different hardware platforms, even if they do not have the
  374. same ordinal value.  Examples are the ISO characters such as the
  375. English pound symbol and other common symbols such as the internatio-
  376. nal quotes ("<<" and ">>") or the Yen symbol.
  377.  
  378. The proposed remapper remaps non standard ASCII characters to the
  379. character set options of the present system.  Remapping may be one
  380. character to one character, one character to two characters or one
  381. character to multiple characters.  The latter requires extra
  382. implementation effort.
  383.  
  384. Example:
  385.   The uppercase "A" with the accent grave "`" above it, will remap on
  386.   all systems that support at least the ISO foreign characters or
  387.   similar character sets.  It will remap to the uppercase "A" in
  388.   standard ASCII.  The user could be allowed the option to view an
  389.   approximation of the original by displaying the "A" followed by the
  390.   "`", but this choice is left to the implementor.
  391.  
  392. The following two kludges are proposed (<charset_kludge> and <char-
  393. set_change>).  The kludge syntax is described in BNF below, comments
  394. are in curly brackets, terminal symbols are in double quotes.
  395.  
  396. Case is important.
  397.  
  398.   <charset_kludge> ::= "^aCHARSET:" <charset_param>
  399.                        | "^aCHRS:" <charset_param>
  400.  
  401. FSC-0054 only writes the CHRS kludge, but for backwards
  402. compatibility with older methods allows CHARSET as a valid kludge.
  403.  
  404. Note: up to the end of the charset kludge, all characters must be
  405. standard ASCII.  Keywords are in English.
  406.  
  407.   <charset_param> ::= <level_1_opt> "1" | <level_2_opt> "2" |
  408.                       <level_3_opt> "3" | <level_4_opt> "4"
  409.  
  410.   <level_1_opt> ::=   "DUTCH" | "FINNISH" | "FRENCH"
  411.                       | "CANADIAN" | "GERMAN" | "ITALIAN"
  412.                       | "NORWEG"  | "PORTU" | "SPANISH"
  413.                       | "SWEDISH" | "SWISS" | "UK"
  414.  
  415. Note: <level_1_opt> represents the 12 different ISO international
  416. replacement characters.  An 8 character limit applies, more charac-
  417. ters may be used by the kludge, but only the above must match.
  418.  
  419.  
  420.   <level_2_opt> ::=   "LATIN-1"
  421.                       | "ASCII" | "IBMPC" | "MAC" | "VT100"
  422.  
  423. <level_2_opt> strings may not exceed 8 characters in length.
  424.  
  425. The Amiga and the VT200, etc. use LATIN-1 extended characters. The
  426. LATIN-1 kludge is the same as in FSC-0051.  The LATIN-1 kludge is used
  427. for the transport medium in the Network.  The others are primarily for
  428. local storage.
  429.  
  430. Note: the other level 2 options can be useful in translating incomming
  431. messages as well.  Example: an IBM system hosts Echomail areas that
  432. concern themselves with Amiga and Macintosh computers, even though the
  433. messages do not have a kludge the local system could translate them
  434. using FSC-0054 to make the extended codes of these machines readable to
  435. his local machine. VT100 is included for local translation of PC
  436. graphics for non-PC based clients. It should not appear on the
  437. network.
  438.  
  439.  
  440.   <level_3_opt> ::=   "Latin-1" | "Latin-2" | "Latin-3" | "Latin-4"
  441.                       | "Latin-5" | "Arabic" | "Cyrillic" | "Greek"
  442.                       | "Hebrew" | "Katakana
  443.  
  444.  
  445. Includes international character sets that can be displayed using not
  446. more than 224 (=256-32) characters, this consists of about 25 language
  447. sets.  The above are the most common.  If you are writing a product
  448. that requires one of the others please contact the me.
  449.  
  450. Latin-1 is included because in level 3 you can switch character sets,
  451. in other words you can switch languages.  This is often the case in
  452. foreign languages, especially in thechnical discussions.  In Japanese
  453. for instance it would not be unusual to see characters from 4 different
  454. character sets.
  455.  
  456.   <level_4_opt> ::=  " | "Hanzi" | "Kanji" | "Korean" | "UNICODE"
  457.  
  458. Hanzi is also known as Chinese, Kanji as Japanese.  Leve 4 Options are
  459. 16 bit characters sets.  This does not mean that messages are twice as
  460. large.  In japanese for example most words are represented with
  461. Katakana (8-bit) with the occasional Kanji character (16-bit) thrown
  462. in.
  463.  
  464. For your reference, the ISO character sets are defined in the standards
  465. document ISO 8859.  Further Arabic is 8859-6, Cyrillic is 8859-5, Greek
  466. is 8859-7, Hebrew is 8859-8, Latin-5 is 8859-9, Latin-4 is 8859-4,
  467. Latin-3 is 8859-3, Latin-2 is 8859-2, Latin-1 is 8859-1, Katakana is
  468. JISX0201.1776-0.  For the level 4 options below Hanzi is GB2312.1980-0,
  469. Kanji is JISX0208.1983-0, Korean is KSC5601.1987-0.  Unicode is not yet
  470. an international standard, it is included for future compatibility.
  471. Your system software will support it if it passes ISO commitee boards.
  472.  
  473. When you implement foreign character sets be sure you conform to the
  474. standards!  Several vendors have taken it upon themselves to define
  475. their own standards, partially this was done because no firm standards
  476. had been set at that date.  Most vendors are correcting thier character
  477. mappings to conform (e.g.: see Microsofts conversion to Latin-1 in
  478. Windows away from the IBM-PC character set).  I do not have all the
  479. documents in machine readable form, if you want to get references I
  480. suggest you go to your local library.  Don't wait until the last minute
  481. though as it is likely that your librarien will need to order some of
  482. the documents.
  483.  
  484. Note: <level_3_opt> and <level_4_opt> strings "imply" additional
  485. changes.  Example the Arabic and Hebrew languages are written from
  486. right to left.  Some character sets may be the same but character
  487. ordering is different.  Character widths may vary to a large extent
  488. (including zero width characters).
  489.  
  490.  
  491.  
  492.  
  493.   <charset_change>::= "^aCHRC:" <switch>
  494.  
  495. Note: use of the charset change kludge REQUIRES the charset kludge at
  496. the beginning of the message.  Also message readers supporting this
  497. kludge do not display a new-line if this kludge is encountered.
  498.  
  499.   <switch> ::=        <level_2_switch> | <level_3_switch>
  500.                       <level_4_switch>
  501.  
  502.   <level_2_switch>::= "D" {default, see below for explanation}
  503.                       | "F " <font_change> | "S " <style_change>
  504.  
  505.  
  506. The string "^aCHRC:D" is a resetting mechanism that turns on the
  507. default settings of the message displayer/editor, whatever they may
  508. be.  This string must be recognized by software that evaluates the
  509. style and font change switch.
  510.  
  511. The It is assumed that the user is seeing some font that has a
  512. reasonable size suitable for his viewing needs.  Most printed texts
  513. are displayed in a serif 12 point, proportional font with no added
  514. style.  Most default settings come close to this representation.  On
  515. text only displays non-proportional fonts are the norm, however as
  516. no rule for the ordering of the displayed characters can be made, an
  517. assumption of a non homogeneous character display can be made.  In
  518. other words, one should not assume that characters are displayed in
  519. a fixed way, thats why we are have the <font_descrip> below.
  520.  
  521.   <level_3_switch>::= <level_2_switch> | "L " <level_3_opt>
  522.                       | "C " <set_change>
  523.  
  524. The character set change option can't be use in level 2 because of
  525. unsatisfacory display results on text only display hardware.  If you
  526. want to change the character set (not just font or style) then you must
  527. support level 3.
  528.  
  529.   <level_4_switch>::= <level_2_switch> | <level_3_switch>
  530.                       | "L " <level_4_opt>
  531.  
  532.   <font_change> ::=   <font_descrip> " " <font_family>
  533.  
  534.   <font_family> ::=   NULL | {any number of fonts family names,
  535.                       examples: Times, Bookman or Helvetica}
  536.  
  537. The font families can be just about any text string, of course if you
  538. have an esoteric font then it is unlikly that the recipient has it as
  539. well (especially in echomail).  It is suggested that the author
  540. recommends that the user use commonly available fonts.  Even if a
  541. particular font is not available to the reader the font descripter will
  542. approximate the display of the original message.
  543.  
  544.   <font_descrip> ::=  <font_descrip1>
  545.                       | <font_descrip1> <font_descrip1>
  546.  
  547.   <font_descrip1> ::= "S" {serif} | "N" {sans-serif}
  548.                       | "P" {proportional} | "O" {other}
  549.  
  550. Note: font_family can be null, but font_descriptor must be there.
  551.  
  552.   <style_change> ::=  <style_change> <style_change>
  553.                       | "b" {Bold}      | "i" {Italic}
  554.                       | "u" {Underline} | "C" {All caps}
  555.                       | "U" {double underline}
  556.                       | "n" {Narrow also known as Condensed}
  557.                       | "w" {Wide also known as Extended}
  558.                       | "s" {Subscript} | "S" {Superscript}
  559.                       | "O" {Outline}   | "h" {Shadow}
  560.  
  561. Note: you may approximate different styles.  For example if you can
  562. only do underline then you can approximate double underline with
  563. underline.  Please do not approximate "All caps"!  All caps shows the
  564. All uppercase letters as large uppercase letters and all lower case
  565. letters as small uppercase letters.  If you simply convert all letters
  566. to uppercase you will misrepresent the intended style.
  567.  
  568.  
  569. Examples:
  570. ---------
  571.  
  572. Double quoted characters are message text.
  573.  
  574.   1) "^aCHRS: GERMAN 1"
  575.        Means text contains German characters, but still uses 7 bit
  576.        character representation.
  577.  
  578.   2) "^aCHRS: IBMPC 2"
  579.        Means the text contains IBM PC graphic or extended characters.
  580.        This would normally only appear in locally held messages.
  581.  
  582.   3) "^aCHRS: LATIN-1 2"
  583.      "^aCHRC:u"
  584.      "Hi Joe,"
  585.      "^aCHRC:D"
  586.        Means the text contains LATIN-1 extended characters (not
  587.        dipslayed in this example) and that "Hi Joe," is underlined.
  588.        Also the "^aCHRC:" kludges do not result in new lines on
  589.        message readers that support these kludges.
  590.        The "CHRS: LATIN-1 2" is compatible with FSC-0051.
  591.  
  592.   4) "^aCHRS: ASCII 2"
  593.        Means the text is standard ASCII, but hidden style and/or font
  594.        changes are contained therein.
  595.  
  596.   5) "^aCHRS: Roman 3"
  597.        Means that a level three editor has created this text.  An
  598.        editor (with the roman character set, thats ours by the way)
  599.        that does not understand level 3 will only be able to read
  600.        this text if the string "^aCHRC:L xxx" (with xxx being
  601.        something other than Roman) is not contained in the text. 
  602.        Actually this should not happen as the Roman font is the
  603.        default and the above kludge implies that another language
  604.        character set is used somewhere in the text.
  605.  
  606. Summary:
  607. --------
  608.  
  609. Level 0:
  610.   This is the initial default mode for CHARSET software.
  611.  
  612.   No additional work required.  However an implementor of CHARSET
  613.   should include the following feature: remap non standard ASCII to
  614.   ASCII.  This is Level 2 to ASCII remapping and is trivial to do.
  615.  
  616.   No kludge is required.  No special handling is required.  The
  617.   messages are just as they always are, with a little less
  618.   non standard ASCII.
  619.  
  620.  
  621. Level 1:
  622.   This is similar to the optional Level 0 remapping but allows the
  623.   use of foreign characters which are found in the ISO character
  624.   sets.  Unfortunately the ISO foreign character sets are not
  625.   complete.  I decided to restrict the Level 1 to this subset to
  626.   assure that compatibility with virtually all hardware is garanteed.
  627.  
  628.   The "^aCHRS: cccccccc 1" kludge is required.  One of two things can
  629.   happen:
  630.        (a) the message is entirely in ASCII (no kludge),
  631.            everybody can read it.
  632.        (b) the message contains ISO codes,
  633.             - the user has an older reader and does not have these
  634.             codes as his default codes, he gets a few garbage
  635.             characters (this is often the case at present).
  636.             - the user has an older reader and has these codes as his
  637.             default, he sees the message properly displayed (e.g.:
  638.             user has an IBM is reading a Swedish area, as he has the
  639.             Swedish codepage loaded; he will see things properly).
  640.             - the user has an editor that supports the charset
  641.             kludge, he sees the message properly displayed.
  642.  
  643.  
  644. Level 2:
  645.   Remaps characters above decimal 127 up to decimal 255 to the "best
  646.   match" character(s) available on the present system.  On graphic
  647.   based systems the use of a different font (e.g.: an IBM-PC font
  648.   on an Amiga) would give perfect display results.  For keyboard
  649.   entry the remapper is required to convert the local codes to the
  650.   codes required by the inteded target.
  651.   Example:  An Amiga user is reading an IBM echomail area.  The IBM
  652.             specific character set is allowed on this echo area.  For
  653.             best results a IBM character set font might be used to
  654.             display messages in the area.  Perhaps the software just
  655.             remaps the IBM characters to the appropriate Amiga
  656.             characters.  When the Amiga user enters text he may (a)
  657.             enter standard ASCII, (b) enter standard ASCII with Level
  658.             1 extensions, (c) enter characters in the IBM extended
  659.             character set.
  660.   The software may optionally support font changing and style
  661.   changes.  Font changes could be easiest to implement on graphically
  662.   oriented systems, text displays could change the color of text.
  663.  
  664.   The "^aCHRS: xxxxx 2" kludge is required.
  665.  
  666.  
  667. Level 3 & 4:
  668.   The message is probably unreadable unless you have a level 3 (or
  669.   level 4) editor.  They are required for true international software
  670.   however.
  671.  
  672.  
  673. Implementation Sample:
  674. ----------------------
  675.  
  676. An easy and fast way to implement such a remapper is to use a look-
  677. up table mechanism.  The implementation described here is based on
  678. an expandable, data driven structure.  The following routines
  679. describe the READ routines.
  680.  
  681. Function Charset_Kludge_Detected (Ptr_To_Text, Level)
  682. {This function implements the basic level 2 requirement}
  683.  
  684.   If our character set then
  685.        print (Text)
  686.  
  687.   If Level = 1 then
  688.        For each character in text
  689.             output( lookup_table [character] )
  690.  
  691.   If Level = 2 then
  692.        If supported character set then
  693.             For each character in text
  694.                  If Kludge then
  695.                       skip it
  696.                       {we are not supporting style and font changes
  697.                       here}
  698.                  If character > 127 then
  699.                       output( lookup_table [character] )
  700.  
  701.   If level = 3 then
  702.        exit with error
  703.        {we are being lazy here}
  704.  
  705. End of Function Charset_Kludge_Detected.
  706.  
  707.  
  708.  
  709. Function Output (character)
  710. {this is the core of the implementation.
  711.  It is also usable in slightly modified form as the write subroutine}
  712.  
  713.   define:
  714.        lookup_table =
  715.             array [0...127 x 2] of type byte
  716.             { = array [127 elements] x [2 elements] }
  717.             {see below for exact definition}
  718.  
  719.   case lookup_table [character][0] of
  720.  
  721.        0...1:
  722.             { we have a single character replacement }
  723.             { IMPORTANT: graphic characters must have a 
  724.               single character match }
  725.             print (lookup_table [character][1])
  726.  
  727.        32...127:
  728.             If lookup_table [character][1] >= 32 then
  729.                  { we have a two character replacement }
  730.                  { Examples: ae, oe, <<, Pt, pi, >=, etc. }
  731.                  print (lookup_table [character][0])
  732.                  print (lookup_table [character][0])
  733.             Else
  734.                  { reserved for implemtors use,
  735.                    e.g.: more than two character replacement? }
  736.  
  737.        1...31:
  738.             { reserved for FSC use }
  739.  
  740.   end of case
  741.  
  742.  
  743. End of Function Output.
  744.  
  745.  
  746. Lookup Table
  747. ------------
  748.  
  749. The lookup_tables are external (described below) files and have the
  750. following format:
  751.  
  752. 4 bytes:         identification
  753. 2 bytes:         module version number
  754. 2 byte:          level
  755. 8 bytes:         reserved for future use (should be zero)
  756. 8 bytes:         from charset
  757. 8 bytes:         to charset
  758. 256 bytes:       lookup table
  759.  
  760. The identification is usually 0 (= FTSC set), numbers less than 65536
  761. are reserved for FSC use.  Implementation specific modules should
  762. use a timestamp (always the same number after it has been generated
  763. once) to mark them as non-standard modules.
  764.  
  765. Module version number starts at zero and works upwards.  The first
  766. official release is "1".  The early sample implementations have version
  767. number "0".
  768.  
  769. Level is the charset kludge level this module is intended for.
  770.  
  771. From charset, is the character set this module translates from.
  772. To charset, is the character set this module translates to.
  773. Both are in C format (no leading length byte and filled up with
  774. zeros).
  775.  
  776. The lookup table is a 127 element table with two bytes per element. 
  777. The following rules apply:
  778.   first byte = 0 or
  779.   first byte = 1:
  780.        second byte = 0: no output
  781.        second byte > 0: second byte is output
  782.   first byte < 32: reserved for FSC use
  783.   first byte > 31:
  784.        second byte > 31: output first & second byte
  785.        second byte < 32: implementation specific switch useable by
  786.                          programmer
  787.  
  788. If the first byte is 1 in the lookup table, that is a marker to
  789. tell you that this character does not translate to the destination
  790. character set.  A "?" should be in the second byte.  Characters
  791. that are approximated with another character do NOT have a 1 as the
  792. first byte, they have a 0 in the first byte, or a printable character
  793. if it is a two character approximation.
  794.  
  795. Note that you require two tables for each type of character set
  796. supported.  One to translate the alien characters to the local format
  797. and one to translate the local characters to the alien format.
  798.  
  799. The advantage of this module system, is that additional "modules" can
  800. be added easily at a later date.  Example: the implementor of an
  801. Atari message editor has the following lookup tables: ASCII (requi-
  802. red), IBMPC, MAC and LATIN-1.  The user wants to take part in a UNIX
  803. echomail that allows VT100 codes, so he gets himself the required
  804. tables and binds them into the lookup table file.  The editor will
  805. now support the additional translations as it knows its capabilities
  806. by looking up the level and the kludge identifier in the lookup table
  807. file.  No code chaging was needed.
  808.  
  809. External Mapping Files
  810. ----------------------
  811.  
  812. The lookup tables above are held in external files (READMAPS.DAT and
  813. WRITMAPS.DAT).  These files have the following format:
  814.  
  815. 1 byte:        machine architecture identifier
  816. 3 bytes:    filler (should be zero)
  817. 8 bytes:    charset this mapping file is for.
  818. Lookup tables:    described above
  819.  
  820. The machine architecture identifier can have one of three values:
  821. 0 = Sparc & 680x0
  822. 1 = 80x86 & VAX
  823. 2 = PDP-11
  824. these values reflect the byte ordering of those machines.
  825.  
  826. The lookup tables should be ordered in the following way:
  827.     o Sort by level (lowest first)
  828.     o READMAPS.DAT:
  829.        - sort by "from set"
  830.        - each from can have 2 tables, the first is to the
  831.          local characterset, the second is to ASCII
  832.     o WRITEMAPS.DAT:
  833.        - sort by "to set"
  834. This allows fast binary tree searches to be done.
  835.  
  836. The appropriate sort code (in C) is given below:
  837.  
  838. int compare_read(r1, r2)
  839. CHARREC    *r1,
  840.     *r2;
  841. {
  842.     /* sort by level first */
  843.     if (r1->level < r2->level)
  844.         return(-1);
  845.     if (r1->level > r2->level)
  846.         return(1);
  847.     /* ASCII comes after local set (this is only for the read_maps) */
  848.     if(strncmp(r1->from_set, r2->from_set, 8) == 0)
  849.     {
  850.     if (strcmp(r1->to_set, "ASCII") == 0)
  851.         return (1);
  852.     if (strcmp(r2->to_set, "ASCII") == 0)
  853.         return(-1);
  854.     }
  855.     /* else sort alpha */
  856.     return(strncmp(r1->from_set, r2->from_set, 8));
  857. }
  858.  
  859. int compare_write(r1, r2)
  860. CHARREC    *r1,
  861.     *r2;
  862. {
  863.     /* sort by level first */
  864.     if (r1->level < r2->level)
  865.         return(-1);
  866.     if (r1->level > r2->level)
  867.         return(1);
  868.     /* if from_set is the same sort the to_set */
  869.     if(strncmp(r1->from_set, r2->from_set, 8) == 0)
  870.     return (strncmp(r1->to_set, r2->to_set, 8));
  871.     /* else sort alpha */
  872.     return(strncmp(r1->from_set, r2->from_set, 8));
  873. }
  874.  
  875.  
  876. Together with this document there should be a sample implementation
  877. containing:
  878.   A complete set of level 1 maps.
  879.   A complete set of level 2 maps (IBM, MAC, VT100 and LATIN-1).
  880.   IBM, Mac and ASCII sample messages containing level 2 kludges, a 
  881.   german language level 1 message, a sample message reader and a sample
  882.   message writer.  A module checker and a mapping file creator.
  883.  
  884. If you want the latest version (or the sample implementation is not
  885. included with this document) you can file request at 2:243/100 with the
  886. magic name CHARSET , 1:1/20 has a copy as well.  The file is also
  887. distirbuted via SDS.
  888.  
  889.  
  890.